home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
The X-Philes (2nd Revision)
/
The X-Philes Number 1 (1995).iso
/
xphiles
/
hp48_2
/
lib.for
/
comp.sys.handhelds_2341_000000.msg
Wrap
Internet Message Format
|
1991-04-12
|
6KB
Path: en.ecn.purdue.edu!noose.ecn.purdue.edu!mentor.cc.purdue.edu!purdue!haven!uflorida!rex!wuarchive!usc!apple!rutgers!ub!acsu.buffalo.edu
From: cloos@acsu.buffalo.edu (James H. Cloos)
Newsgroups: comp.sys.handhelds
Subject: Today the subject is libraries (LONG)
Keywords: libraries, finally
Message-ID: <46387@eerie.acsu.Buffalo.EDU>
Date: 15 Nov 90 03:47:24 GMT
Sender: news@acsu.Buffalo.EDU
Followup-To: comp.sys.handhelds
Distribution: comp
Organization: State University of New York @ Buffalo
Lines: 123
Yup, you guessed it; I spent the last few hours pouring over hex dumps
of libraries, both created from directories by usrlib, and some from
the bbs. Anyway, this is what I found out:
(NB, each of these fields is individually reversed in memory; unlike
the dir posting, I'll write these in readable format.)
A library looks like this:
#02b40 LIB header
#nnnnn size of the library, incl this field.
#nn the length of the lib's name, in chars
(If the lib is unnamed, this is #00 and the next two fields are missing)
asciiascii the name of the library
#nn the length of the lib's name, again
(Now back to always there mode :)
#nnn the LIB's id number
#nnnnn offset to hash table \
#nnnnn offset to message arry | offsets are from the start of
#nnnnn offset to link table | the offset field
#nnnnn ofset to config object /
the data follows.
Named xlibs are stored in the format:
#000 or #8 000=ok in alg expressions, 8= not ok in algebraics
#nnn lib's id number from above
#nnn the xlib's member number
the actual object, starting w/ a std type field.
(You'll find that lib #002 (the usrlang commands) is stored this way also.)
Unnamed xlib's are stored w/o the #000nnnmmm or #8nnnmmm header, so
you just start w/ the type field.
The config object is what is evaluated after each system halt, and is
usually a program. To borrow from the usrlib doc file, make sure this
DOES NOT LEAVE ANYTHING ON THE STACK OR DROP ANYTHING THAT WAS THERE.
My assumption is that only a ram clear will fix the 48 if there is a
lib installed that has a bad config obj, as the post-system-halt
routines will probably crash each time you try one.
The link table is a hex string (a la a binary integer, but with a max
wordsize of 2^5 - 6 nybbles) (proof of that is left as an exersise for
the reader). This hex string is 5 nybbles long per XLIB in the
library, and each group of 5 nyb's forms an offset from the table to
the beginning of the type field of each xlib. These offsets are
signed, so if this table is after the actual XLIB's, the offsets
will be the complement (as per the NEG key on a binary integer--I'm
too tired to figure out if this is 1's or 2's ;) of the actual
distance from the field to the XLIB. These are the only signed
offsets I'm aware of so far, though maybe all offsets are, check your
local saturn guru for details. ;)
The message array is a simple array of strings. (Which have the format:
#029e8 type of ARRY
#nnnnn size of array, incl this field
#02a2c type of data in general, #2a2c is string type
#nnnnn number of dimentions
#nnnnn number of elements in 1st dimention
...
#nnnnn '' '' '' '' nth ''
data
Where data is sum(i=1,no_of_dims,no_of_elem_in_this_dim) elements of
the type specified. In the case of strings, each of these looks like
a 5 nybble size field (in nyb's incl itself) plus the ascii chars in
the string.)
This leaves the hash table. This is also a hex string. At the end of
this hex string are 5 nyb pointers for each named XLIB which point to
that XLIB's name. These names immediately precede the pointers.
These offsets, though pointing backwards, are positive (or unsigned?),
ie., #00020 would point 32 nybbles back from the start of itself.
The names these point to are in the familiar global name format, ie a
2 nybble size field (in char's, excluding itself) followed by that
many bytes of ascii (each of course in reverse nybble order). This is
followed by a 3 nybble field of that XLIB's member number. Before
this is a 5 nyb field that is the length, in nybbles, of itself, & each
of the XLIB names (inlc that name's length field and number field).
Before all this, in each of the lib's I've looked at, is 85 nybbles of
mostly 0's. They seem to be 16 fields of 5 nybbles each (resonable
thought) and there would seem to be on the order of 3 or so of these
fields that contain any non zero data, this is usually only 2 nybbles.
I presume they are some sort of offset, but to where (or from where
for that matter) I've no idea.
The CONFIG, MESSAGE, LINK, HASH, and each individual XLIB can be, so
far as I can tell, in any order, so long as each is itself contiguous ;^)
I would presume, however, that there is some performance penalty if
they are all mixed around, as minor as that might be (though if you
use a XLIB in such a library in a type loop, these penalties could
amount to a noticable delay). (My compiler will use a standard order
which is the easiest for me to put together. ;)
I better leave now, before I go over 900 words; I've already passed
100 lines. Enjoy this info. & like the post on dir's, if you don't
understand it, ask & someone (maybe even me) will try to explain it
better. This *is* fun. Trust me. Really. Would *I* lie to you?
Seriously. As much as this looks sarcastic, it isn't. I promise.
BTW, the library: "04B20E10000066600000000000000000000577E" (in ASC
format) is nothing but an unnamed lib, lib# = 666h = 1638d, w/o
anything in it. ASC\-> will work on the string, resulting in :
`Library 1638: ` on the stack (w/o the `'s of course). I'm not going
to try installing it, as I don't feel like a mem lost just now. Could
someone out there who has a handy archive try this and report on it?
L8r, ffolks.
-JimC
--
James H. Cloos, Jr. Phone: +1 716 673-1250
cloos@ACSU.Buffalo.EDU Snail: PersonalZipCode: 14048-0772, USA
cloos@ub.UUCP Quote: <>
THIS INFORMATION COMES WITHOUT ANY FORM OF WARRENTY, NOT EVEN IMPLIED ONES.